Federated Credential Management API

Draft Community Group Report,

This version:
http://wicg.github.io/FedCM
Test Suite:
https://github.com/web-platform-tests/wpt/blob/master/credential-management/webid.https.html
Issue Tracking:
GitHub
Editor:
(Google Inc.)

Copyright © 2021 the Contributors to the Federated Credential Management API Specification, published by the Web Platform Incubator Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification defines a set of high-level APIs that enables users to continue to use Identity Providers to authenticate to Relying Partys without incurring into Unsanctioned Web Tracking. It accomplishes that by exposing the explicit user controls needed to manage the lifecycle of their federated accounts.

Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This section is non-normative.

Over the last decade, identity federation has unquestionably played a central role in raising the bar for authentication on the web, in terms of ease-of-use (e.g. passwordless single sign-on), security (e.g. improved resistance to phishing and credential stuffing attacks) and trustworthiness compared to its preceding pattern: per-site usernames and passwords.

The standards that define how identity federation works today on the Web were built independently of the Web Platform (namely, SAML, OpenID and OAuth), and their designers had to (rightfully so) work around its limitations rather than extend them.

Because of that, existing user authentication flows were designed on top of general-purpose web platform capabilities such as top-level navigations/redirects with parameters, window popups, iframes and cookies.

However, because these general purpose primitives can be used for an open ended number of use cases (again, notably, by design), browsers have to apply policies that capture the lowest common denominator of abuse, at best applying cumbersome permissions (e.g. popup blockers) and at worst entirely blocking them (e.g. blocking third party cookies).

Over the years, as these low-level APIs get abused, browsers intervene and federation adjusts itself. For example, popup blockers became common and federation had to adjust itself to work in a world where popups blockers were widely deployed.

The challenge is that some of these low level primitives are getting increasingly abused to allow users on the web to be tracked. So, as a result, browsers are applying stricter and stricter policies around them.

This specification defines a set of high-level APIs that serve as a foundation where identity federation on Web can thrive without incurring into Unsanctioned Web Tracking.

2. Use Cases

The below use case scenarios illustrate some basic supported flows. Additional scenarios, including sample code, are given later in the Identity Use Cases in Browser Catalog.

2.1. Sign-up

A Sign-up occurs when the user is registering a new account at the Relying Party using their Identity Provider.

2.2. Sign-in

After a user navigates to a Relying Party in a browser and decides to create an account by going through their § 2.1 Sign-up flow, there are two ways a user logs into their account once their session expires:

2.2.1. Auto Sign-in

Auto Sign-in occurs when the Identity Provider has already gathered enough permission from the user to share their identity that it doesn’t block on gathering further permission and automatically signs the user in.

2.2.2. Explicit Sign-in

An explicit sign-in occurs when the Identity Provider believes it is necessary to gather an explicit permission from the user to sign into a Relying Party, typically after the user goes through a § 2.3 Sign-out flow.

A few months later:

2.3. Sign-out

After a user navigates to a Relying Party in a browser and decides to create an account by going through their § 2.1 Sign-up flow, there are two ways a user can clear their sessions:

2.3.1. RP Sign-out

2.3.2. IDP Sign-out

2.4. Revocation

After a user navigates to a Relying Party in a browser and decides to create an account by going through their § 2.1 Sign-up flow, there are two ways a user can cancel their account:

2.4.1. IDP Revocation

2.4.2. RP Revocation

2.5. Access

3. Examples

This specification extends the FederatedCredential type and internal algorithms to allow the exchange of identity between IDPs and RPs. When it succeeds, it returns to the RP a signed id token which the RP can use to authenticate the user.

<html>
  <head>
    <title>Welcome to my WebSite!</title>
  </head>
  <body>
    <button onclick="login('https://foo.example', '123')">Sign-in with Foo</button>
    <button onclick="logout()">logout</button>

    Welcome <span id="name"></span>!!

    <button onclick="revoke">delete account</button>

    <script>

    var user;

    async function login(provider, clientId) {
      const {idToken} = await navigator.credentials.get({
        // controls whether auto sign-in is enabled or not
        mediation: "optional",
        // controls abortions of the account chooser
        signal: signal

        // controls which identity providers to use
        federated: {
          // controls whether the account chooser is modal or not
          providers: [{
            url: provider,
            // the pre-registered client id
            clientId: clientId,
            nonce: "456"
          }],
        }
      });

      // ... do stuff ...
      // ... send to server ...
      // ... validate ...
      // ... update local storage ...

      user = parse(idToken);
      document.getElementById("name").innerText = user.name;
    }

    async function logout() {
      await navigator.credentials.preventSilentAccess();
    }

    async function revoke() {
      await FederatedCredential.revoke(user.id);
    }
    </script>
  </body>

</html>

4. Terminology

HTML Standard defines an origin as the tuple of a scheme, hostname, and port that provides the main security boundary on the web.

A site is a set of origins that are all same site with each other. Note that there are problems (Public Suffix List Problems) with using registrable domains as a logical boundary.

A party is defined by Tracking Preference Expression (DNT) as "a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user."

The first party for a user action is the party that controls the origin of the top-level browsing context under which the action happened. Intuitively, this is the owner of the domain in the browser’s URL bar. This differs from Mozilla’s definition in that Mozilla defines other parties as first parties if the user can easily discover which party it is and intends to interact with that party, for example to allow sign-in widgets to be first-party.

A third party for a user action is any party that isn’t the first party or the user (the second party).

A user is a human or program that controls a user agent.

A user identifier is a pair of a site and a (potentially-large) integer allocated by that site that is used to identify a user on that site. A single user will generally have many user IDs that refer to them, and a single site may or may not know that multiple user identifiers refer to the same user.

A global identifier is a string that identifies a particular user independent of which site they’re visiting (e.g. email addresses and phone numbers). Users generally have relatively few global identifiers and can usually list and recognize them. A goal of anti-tracking policy is to prevent user identifiers from becoming global identifiers.

A directed identifier is a user identifier that that is unique for each site they’re visiting. A goal of anti-tracking policy is to promote user identifiers to become directed identifiers.

Relying Party
RP
Website

TODO(goto): find existing definitions.

Identity Provider
IDP

TODO(goto): find existing definition.

session

TODO(goto): find existing definition.

account

TODO(goto): find existing definition.

id token

TODO(goto): find existing definition.

unsactioned tracking

Unsanctioned Web Tracking

high-level API

A use case specific API, as opposed to a low-level API. See also high level vs low level.

low-level API

A general purpose API, as opposed to a high-level API. See also high level vs low level

registered

TODO(goto): find existing definition.

unregistered

TODO(goto): find existing definition.

logged in

TODO(goto): find existing definition.

logged out

TODO(goto): find existing definition.

out-of-band

Outside of the user agent’s context.

joining

5. High Level Design

At a high level, the Identity Federation Management API works by the intermediation of cooperating IDPs and RPs.

The § 6 The Identity Provider API and the § 7 The Relying Party API defines a set of HTTP APIs that cooperating IDPs and IDPs exposes as well as the entry points in the § 8 The Browser API that they can use.

The user agent intermediates in such a matter that makes it impractical for the API to be used for tracking purposes, while preserving the functionality of identity federation.

This document defines the APIs in the following order:

  1. The § 6 The Identity Provider API

  2. The § 7 The Relying Party API

  3. The § 8 The Browser API

6. The Identity Provider API

The IDP proactively and cooperatively exposes itself as a comformant agent by exposing a series of HTTP endpoints:

  1. A § 6.1 Manifest endpoint in a well-known location that points to

  2. An § 6.2 Accounts List endpoint

  3. A § 6.3 Client Metadata endpoint

  4. An § 6.4 ID Token endpoint

  5. A § 6.5 Revocation endpoint

6.1. Manifest

The well-known discovery endpoint is an endpoint located at the IDP's .well-known/federated-credentials and serves as a discovery device to other endpoints provided by the IDP.

The well-known discovery endpoint is fetched (a) without cookies and (b) with a special § 6.6 Sec-FedCM-CSRF header.

For example:

GET /.well-known/federated-credentials HTTP/1.1
Host: idp.example
Accept: application/json
Sec-FedCM-CSRF: random_value

The file is parsed expecting the following properties:

accounts_endpoint

A URL that points to an HTTP API that complies with the § 6.2 Accounts List API.

client_id_metadata_endpoint

A URL that points to an HTTP API that complies with the § 6.3 Client Metadata API.

idtoken_endpoint

A URL that points to an HTTP API that complies with the § 6.4 ID Token API.

revocation_endpoint

A URL that points to an HTTP API that complies with the § 6.5 Revocation API.

For example:

{
  "accounts_endpoint": "/accounts.php",
  "client_id_metadata_endpoint": "/metadata.php",
  "idtoken_endpoint": "/idtokens.php",
  "revocation_endpoint": "/revocation.php"
}

6.2. Accounts List

The accounts list endpoint provides the list of accounts the user has at the IDP.

The accounts list endpoint is fetched (a) with any cookies and (b) with a special § 6.6 Sec-FedCM-CSRF header.

For example:

GET /accounts_list.php HTTP/1.1
Host: idp.example
Accept: application/json
Cookie: 0x23223
Sec-FedCM-CSRF: random_value

The response is expected to have the following properties:

accounts (required)

A list of Account JSON.

Every Account JSON is expected to have the following properties:

account_id (required)

An account identifier.

name (required)

The user’s full name.

given_name (required)

The user’s given name.

email (optional)

The user’s email address.

picture (optional)

The user’s profile picture.

For example:

{
 "accounts": [{
   "account_id": "1234",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
  }, {
   "account_id": "5678",
   "given_name": "Johnny",
   "name": "Johnny",
   "email": "johnny@idp.example",
   "picture": "https://idp.example/profile/456"
  }]
}

6.3. Client Metadata

The client metadata endpoint provides metadata about RPs.

The client medata endpoint is fetched (a) without cookies and (b) with a special § 6.6 Sec-FedCM-CSRF header.

The user agent also passes the client_id.

For example:

GET /client_medata.php?client_id=1234 HTTP/1.1
Host: idp.example
Accept: application/json
Sec-FedCM-CSRF: random_value

The file is parsed expecting the following properties:

privacy_policy_url

A link to the RP's privacy policy.

terms_of_service_url

A link to the RP's terms of service.

For example:

{
  "privacy_policy_url": "/privacy.html",
  "terms_of_service_url": "/terms.html",
}

6.4. ID Token

The ID Token endpoint is responsible for minting a new id token for the user.

The ID Token endpoint is fetched (a) as a POST request, (b) with cookies and (c) with a special § 6.6 Sec-FedCM-CSRF header.

It will also contain the following parameters passed as a JSON object:

account_id

The account identifier that was selected.

request

The RP request

The RP request has the following properties:

client_id

The RP's client it

nonce

A random number of the choice of the RP

For example:

POST /fedcm_token_endpoint HTTP/1.1
Host: idp.example
Referer: rp.example
Content-Type: application/json
Cookie: 0x23223
Sec-FedCM-CSRF: random_value
{
  "account_id": "123",
  "request": {
    "client_id": "client1234",
    "nonce": "Ct60bD"
  }
}

The response is parsed as a JSON file expecting the following properties:

id_token

The resulting id token.

For example:

{
  "id_token" : "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c"
}

6.5. Revocation

The revocation endpoint is responsible for revoking all id tokens for the specified client ID for the user.

The revocation endpoint is fetched (a) as a POST request, (b) with cookies, (c) with a special § 6.6 Sec-FedCM-CSRF header, and (d) with a Referer header indicating the RP URL.

It will also contain the following parameters passed as a JSON object:

account_id

The account identifier for the user (e.g. email).

request

The revocation request

The revocation request has the following properties:

client_id

The RP's client id

For example:

POST /fedcm_revocation_endpoint HTTP/1.1
Host: idp.example
Referer: rp.example
Content-Type: application/json
Cookie: 0x23223
Sec-FedCM-CSRF: random_value
{
  "account_id": "123",
  "request": {
    "client_id": "client1234"
  }
}

If successful, the response is an empty response with an HTTP 204 code, otherwise an HTTP error code.

6.6. Sec-FedCM-CSRF

7. The Relying Party API

RP's expose a § 7.1 Logout to facilitate with § 2.3.2 IDP Sign-out.

7.1. Logout

When IDPs call the § 8.4.2 IDP Sign-out API, every RP gets a chance to log the user out (e.g. clear cookies, clear local storage) via the logout endpoint.

The logout endpoint is an endpoint that is registered with the IDP out-of-band.

The logout endpoint is called (a) with a GET and (b) with the RP's cookies.

Note: the logout API introduces a credentialed request from the IDP to the RPs, so it exposes a potential tracking surface area. It is a fairly limited and controlled tracking area because the logout API is only available when accounts and sessions are already established between the IDP and the RP.

8. The Browser API

The Browser API exposes APIs to RPs and IDPs to call and intermediates the exchange of the user’s identity.

For RPs, it allows them to:

  1. The § 8.2 The Sign-in API allows RP's users to § 2.1 Sign-up and § 2.1 Sign-up

  2. The § 8.3 The Revocation API allows RP's users to go through § 2.4.2 RP Revocation of their accounts

  3. The § 8.4.1 RP Sign-out API allows RPs to § 2.3.1 RP Sign-out of their accounts.

For IDPs, it allows them to:

  1. The § 8.4.2 IDP Sign-out API allows IDPs to § 2.3.2 IDP Sign-out of their accounts.

The Browser API manages the lifecycle of the user’s accounts and sessions with an internal § 8.1 The State Machine.

8.1. The State Machine

Internally, the account management and session management APIs allows the user to explicitly move through the different stages of their accounts. At each stage, the state machine manages the RP's and the IDP's access to the appropriate browser capabilities.

Account State

Keeps track of whether the user has an account or not. Can be registered or (by default) unregistered.

Session State

Keeps track of whether the user has an open or closed session. Can be logged in or (by default) logged out.

8.2. The Sign-in API

8.2.1. RP Sign-in API

The Sign-up and Sign-in APIs are APIs used by the Relying Partys to ask the browser to intermediate the relationship with the Identity Provider and the provisioning of an id token.

The Relying Party makes no delineation between Sign-up and Sign-in, but rather call the same API indistinguishably. The most important parameter to the API call is the set of Identity Providers that the Relying Party supports and has pre-registered with (i.e. it has a clientId).

Additionally, the Relying Party can control a variety of UX knobs. For example, whether to allow an § 2.2.1 Auto Sign-in flow and an AbortSignal in case it needs to abort the flow.

If all goes well, the Relying Party receives back an id token in the form of a signed JWT which it can use to authenticate the user.

async function login(signal) {
  const {idToken} = await navigator.credentials.get({
    // controls whether auto sign-in is enabled or not
    mediation: "optional",
    // controls abortions of the account chooser
    signal: signal

    // controls which identity providers to use
    federated: {
      // controls whether the account chooser is modal or not
      providers: [{
        url: "https://idp.example",
        // the pre-registered client id
        clientId: "123",
        nonce: "456"
      }],
    }
  });

  return idToken;
}

To accomplish that, this specification does three things:

  1. It extends FederatedCredential with more fields.

  2. It redefines FederatedCredential's [[DiscoverFromExternalSource]]().

  3. It extends FederatedCredentialRequestOptions with more options.

First, this specification extends the FederatedCredential type adding two more fields:

enum FederatedCredentialApprovedBy {
  "auto",
  "user"
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  readonly attribute USVString idToken;
  readonly attribute FederatedCredentialApprovedBy approvedBy;
};
idToken

The id token.

approvedBy

When used in conjunction with mediation, it indicates whether the credential was provided via a § 2.2.1 Auto Sign-in or an § 2.2.2 Explicit Sign-in.

Second, it extends the FederatedCredentialRequestOptions by adding a list of FederatedIdentityProviders:

partial dictionary FederatedCredentialRequestOptions {
  sequence<(DOMString or FederatedIdentityProvider)> providers;
};

dictionary FederatedIdentityProvider {
  required USVString url;
  USVString clientId;
  USVString nonce;
};

And finally, this specification overrides the FederatedCredential's [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) Method.

This algorithm runs in parallel inside the Credential Management § algorithm-request to request credentials and returns a set of FederatedCredential objects from a remote Identity Provider.

This internal method accepts three arguments:

origin

This argument is the relevant settings object's origin, as determined by the calling get() implementation, i.e., CredentialsContainer's Request a Credential abstract operation.

options

This argument is a CredentialRequestOptions object whose options.federated member contains a FederatedCredentialRequestOptions object specifying the exchange options.

sameOriginWithAncestors

This argument is a Boolean value which is true if and only if the caller’s environment settings object is same-origin with its ancestors. It is false if caller is cross-origin.

When this method is invoked, the user agent MUST execute the following algorithm:

  1. If sameOriginWithAncestors is false, return a "NotAllowedError" DOMException.

    Note: This restriction aims to address the concern raised in Security Origin Confusion.

  2. Assert: options["federated"]["providers"] exists.

  3. Assert: options["federated"]["providers"] size is 1.

    Note: At some point we would like to support choosing accounts from multiple Identity Providers.

  4. Let provider be options["federated"]["providers"][0].

  5. Assert: provider["url"] exists.

  6. Assert: provider["clientId"] exists.

  7. Assert: provider["nonce"] exists.

  8. Let wellknown be the result of running the fetch the well-known algorithm with the provider.

  9. Let accounts list be the result of running the fetch the accounts list algorithm.

  10. Let account be the result of running the select an account from the accounts list algorithm.

  11. If the Account State is unregistered

    1. Return the result of running the sign-up algorithm.

  12. If the Session State is logged out then

    1. Return the result of running the explicit sign-in algorithm.

  13. Return the result of running the auto sign-in algorithm.

To sign-up the user run this algorithm:

  1. Gather explicit intent to create an account

  2. Gather explicit agreement with the Privacy Policy

  3. Gather explicit agreement with the Terms of Service

  4. Set the account’s Account State from unregistered to registered.

  5. Set the account’s Session State from logged out to logged in.

  6. Return the result of minting a new id token.

To select an account from the accounts list run this algorithm:

  1. If accounts list’s size is 1

    1. Let account be accounts list[0]

    2. Return account

  2. Display an account chooser

  3. Let account be an account that the user manually selects from the accounts chooser

  4. Return account

To sign-in the user run this algorithm:

  1. Assert that the Account State is registered

  2. Set the account’s Session State from logged out to logged in.

  3. Return the result of minting a new id token.

To auto sign-in the user run this algorithm:

  1. Return the result of running the sign-in algorithm.

To explicit sign-in the user run this algorithm:

  1. Gather explicit confirmation that the user wants to sign-in to Relying Party with their Identity Provider's account

  2. Return the result of running the sign-in algorithm.

To fetch the well-known configuration file, run this algorithm:

  1. Let the wellknown url be the relative url ".well-known/federated-credentials" of provider["url"]

  2. Return the result of fetching the wellknown url with the Sec-FedCM-CSRF header but without the Identity Provider's cookies.

To fetch the accounts list run this algorithm:

  1. Let the acccounts_endpoint url be the relative url wellknown["accounts_endpoint"] of provider["url"]

  2. Let the accounts list be the result of fetching the accounts_endpoint with the Identity Provider's cookies.

  3. Return the accounts list

To fetch the client id metadata run this algorithm:

  1. Let the client_id_metadata_endpoint url be the relative url wellknown["client_id_metadata_endpoint"] of provider["url"]

  2. Let the policies be the result of fetching the client_id_metadata_endpoint with the Sec-FedCM-CSRF header but without the Identity Provider's cookies.

  3. Return policies

The Privacy Policy are the policies described at privacy_policy_url.

The Terms of Service are the policies described at terms_of_service_url.

To mint a new id token, run the following algorithm:

  1. Let token be the result of making a POST request to the wellknown["idtoken_endpoint"] with:

  2. Return a new FederatedCredential as:

8.2.2. IDP Sign-in API

The IDP Sign-in API allows an IDP to sign the user into a RP by storing a FederatedCredential that can later be retrieved by a RP.

Its effect is equivalent to the § 8.2.1 RP Sign-in API in its effect, except that it is designed to be called while the user is at the IDP rather than at the RP.

async function login({id, name, iconURL}) {
  const credential = new FederatedCredential({
    id: id,
    provider: 'https://idp.example',
    name: name,
    iconURL: iconUrl,
    client_id: "1234",
  });

  return await navigator.credentials.store(credential);
}

8.3. The Revocation API

Whenever the user decides to delete their account on the Relying Party the Relying Party can call an API to let the Identity Provider and the browser know.

Upon return to the Relying Party, the user goes through a § 2.1 Sign-up flow instead of a § 2.2 Sign-in flow.

async function revoke(accountId) {
  return await FederatedCredential.revoke(accountId);
}

This specification extends the FederatedCredential interface with an extra static method:

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  static Promise<void> revoke(USVString accountId);
};

Note: go over the revocation API.

8.4. The Sign-out API

8.4.1. RP Sign-out

When a user wants to log out of their session in the Relying Party, the Relying Party can let the browser know that it wants the § 2.2.1 Auto Sign-in flow to be disabled, so that the user doesn’t get into an infinite loop.

It does so by calling the preventSilentAccess() API, which clear the user’s current account session and takes them to an § 2.2.2 Explicit Sign-in flow whenever the user wants to log back in.

function logout() {
  navigator.credentials.preventSilentAccess();
}

Note: go over the RP sign-out API.

8.4.2. IDP Sign-out

In enterprise scenarios, it is common for the user to want to clear all of their existing sessions in all of the Relying Partys they are logged into.

It does so by being navigated to their Identity Provider who initiates what’s called a Front-Channel Logout.

The browser exposes an API that takes the list of Relying Partys that the Identity Provider wants to initiate the logout which are loaded in parallel with cookies.

Each Relying Party endpoint is responsible for clearing its local state (e.g. clearing cookies).

After the completion of this API, the user’s session is cleared and will go through an § 2.2.2 Explicit Sign-in upon return.

async function logout() {
  await FederatedCredential.logout([{
      endpoint: "https://rp1.example",
      accountId: "123",
    }, {
      endpoint: "https://rpN.example",
      accountId: "456",
    }]);
}

IDPs can call FederatedCredential.logout(...) to log the user out of the RPs they are signed into.

dictionary FederatedCredentialLogoutRequest {
    required USVString endpoint;
    required USVString accountId;
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  static Promise<void> logout(optional sequence<FederatedCredentialLogoutRequest> logout_requests = []);
};

Note: go over how this is implemented.

8.5. Backwards Compatibility

Note: go over how we are planning to deal with backwards compatibility.

9. Security

Note: go over security.

10. Privacy

10.1. Privacy Threat Model

This section is intended to provide a comprehensive overview of the privacy risks associated with federated identity on the web for the purpose of measuring the privacy risks and benefits of proposed browser intermediation designs.

See also:

10.1.1. Principals

This section describes the three principals that would participate in an invocation of the API and expectations around their behavior.

  1. The User Agent implements § 8 The Browser API and controls the execution contexts for the RP and IDP content. The user agent is assumed to be trusted by the user, and transitively trusted by the RP and IDP.

  2. Relying Partys (RPs) are first party websites that invoke the FedCM API for the purpose of authenticating a user to their account or for requesting information about that user. A well-behaving RP would only invoke the API following a clear user signal -- typically, clicking a sign-in button. Since any site can invoke the API, RPs cannot necessarily be trusted to limit the user information it collects or use that information in an acceptable way.

  3. Identity Providers (IDPs) are third party websites that are the target of a FedCM call to attempt to fetch an ID token. Usually the IDP has a higher level of trust than the RP since it already has the user’s personal information, but it is possible that the IDP might use the user’s information in non-approved ways. It is possible that the IDP specified in the API call may not be an IDP the user knows about, or may not be a bona fide IDP at all, in which case it likely does not have personal user information in advance, but also might be less accountable for its behavior.

10.1.2. High-level threats

Privacy Considerations for Internet Protocols describes the following high-level privacy threats, which the TAG has adopted into Self-Review Questionnaire: Security and Privacy § threats:

Surveillance

Surveillance is the observation or monitoring of an individual’s communications or activities.

Stored Data Compromise

End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access.

Intrusion

Intrusion consists of invasive acts that disturb or interrupt one’s life or activities.

Misattribution

Misattribution occurs when data or communications related to one individual are attributed to another.

Correlation

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined.

Identification

Identification is the linking of information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity.

Secondary Use

Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.

Disclosure

Disclosure is the revelation of information about an individual that affects the way others judge the individual.

Exclusion

Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use.

These threats combine into the particular concrete threats we want web specifications to defend against, described in subsections here:

10.1.3. Attack Scenarios

This section describes the scenarios in which various agents might attempt to gain user information. It considers the possibilities when:

For the purposes of this section, a principal is considered to be participating in the collection of information if it directly or indirectly performs actions with the aim of realizing one of the above threats.

Note: An example of indirect collusion would be an RP importing a script supplied by an IDP where the IDP intends to track users.

For the purpose of discussion this document assumes that third-party cookies are disabled by default and are no longer effective for use in tracking mechanisms, and also some form of mitigations are implemented against ‘bounce tracking’ using link decoration or postMessage. Most of these scenarios consider how user tracking might happen without them.

See also:

  1. Pervasive Monitoring Is an Attack

10.1.3.1. By the RP
10.1.3.1.1. Cross-Site Correlation

Related to:

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined.

This attack happens when multiple RPs collude to use their user’s data to correlate them and build a richer profile.

When a user willingly provides their full name, email address, phone number, etc, to multiple relying parties, those relying parties can collaborate to build a profile of that user and their activity across collaborating sites.

Sometimes this is referred to as joining since it amounts to a join of user records between the account databases of multiple RPs.

This correlation and profile-building is outside the user’s control and entirely out of the User Agent’s or IDP’s view.

  1. User signs into RP1 (which sells jewelry) with an IDP, providing to RP1 their email address user@email.example

  2. User signs into RP2 (which sells houses) with an IDP, providing to RP2 their email address user@email.example

  3. User browses the collection of wedding rings in RP1.

  4. Out of band, RP1 tells RP2 that user@email.example is shopping for wedding rings

  5. User browses the housing inventory in RP2.

  6. RP2 uses the fact that the user is shopping for wedding rings in RP1 to advertise and filters their housing inventory.

  7. User is surprised that RP2 knows that they are shopping for wedding rings.

A generalization of § 10.1.3.1.1 Cross-Site Correlation is:

(RP Secondary Use) Relying Party uses user information for purposes not authorized by the user:

When the user agrees to allow the IDP to provide information to the RP, the consent is specific to certain purposes, such as sign-in and personalization. The RP might use that data for other purposes that the user would not expect and did not authorize, such as selling email addresses to a spam list.

Spamming risk can exist even when using directed identifiers.

10.1.3.1.2. Same-Site Identification

Identification is the linking of information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity.

This attack happens when the Relying Party employs client state-based tracking to identify user.

Any API that exposes any kind of client state to the web risk becoming a vector for fingerprinting or ‘supercookies’.

This risk would be increased by any proposal for browser mediation that adds directly (or indirectly) detectable client state.

For example, an RP can use the browser state of the FedCM to add bits of entropy and fingerprint the user.

See also:

  1. Mitigating Browser Fingerprinting in Web Specifications

10.1.3.1.3. Data Compromise

This attack scenario happens when the RP takes advantage of inadequate measures (by the IDP or the UA) to secure stored data to obtain personal user information without their consent.

This can happen if user consent mechanisms are missing, inadequate, or susceptible to bypass.

An RP can use clickjacking to trick the user into signing-into their site.
An RP can impersonate another RP to phish the user into signing-into their site.

See also:

  1. Target Privacy Threat Model § stored-data-compromise

  2. Privacy Considerations for Internet Protocols § section-5.1.2

10.1.3.2. By the IDP
10.1.3.2.1. Secondary Use

Related to:

Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.

This attack happens when Identity Providers misuses the the information collected to enable sign-in for other purposes.

Existing federation protocols require that the IDP know which service is requesting an ID token in order to allow identity federation (e.g. the IDP must know the OAuth client_id).

Identity providers can use this fact to build profiles of users across sites where the user has decided to use federation with the same account. This profile could be used, for example, to serve targeted advertisements to those users browsing on sites that the IDP controls.

This risk can exist even in the case where the IDP does not having pre-existing user account information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the IDP are credentialed. This is more likely to occur if the RP is colluding with the IDP to enable tracking; expanded variants are described in § 10.1.3.3.3 Timing Attacks.

  1. User signs into RP1 (which sells jewelry) with an IDP.

  2. User signs into RP2 (which sells houses) with the same IDP.

  3. User navigates to the IDP.

  4. Because the IDP knows that the user has an account with RP1 and RP2, the IDP can show ads about vacations for honeymoons.

  5. The user is surprised that their IDP is aware of their plans to get married.

10.1.3.2.2. Impersonation

Since IDPs have unconstrained ability to issue ID tokens, they are capable of logging in to users’ federated accounts without user knowledge or action, impersonating the user and potentially gaining full access to the user’s account on the RP.

  1. User signs into RP1 (which is a online dating site) with an IDP.

  2. An evil employee at IDP is an ex-spouse of the user.

  3. The evil employee impersonates themselves as the User and gains access to RP1

  4. The evil employee looks at the user’s dating history.

  5. The user is surprised by their ex-spouse’s knowledge of their recent dating affairs.

10.1.3.3. By Collusion
10.1.3.3.1. Intrusion

From Target Privacy Threat Model § hl-intrusion

Privacy harms don’t always come from a site learning things.

From RFC6973: Intrusion

Intrusion consists of invasive acts that disturb or interrupt one’s life or activities. Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or interrupt their activities.

In the context of federation, intrusion happens when an RP and an IDP are colluding to invasively and aggressively recommend the user to login disproportionally to the their intent.

Much like unsolicited notifications, an RP can collude with an IDP to aggressively log users in.

See also:

  1. Web Platform Design Principles § safe-to-browse

10.1.3.3.2. Back channel

This attack scenario happens when IDP exceed the user’s information sharing permission.

Existing federated identity protocols are clear on what information an RP is requesting, which the IDP can provide. While the browser can inspect the request and response and consider whether user permission has been granted for that transfer, it is difficult to know that there is no additional information embedded in the response. An example could be if the IDP encodes an identifier that could be used to load user-targeted advertisements on RP pages, which could be of value where the IDP has much more profiling information about the user.

Another example is if identifying information is shared out-of-band, invisible to the browser, in which case it could contain anything.

  1. User signs into RP1 (which sells jewelry) with an IDP, providing to RP1 their directed identifier email address SHA256(user + RP1)@email.example

  2. User signs into RP2 (which sells houses) with an IDP, providing to RP2 their directed identifier email address SHA256(user + RP2)@email.example

  3. User browses the collection of wedding rings in RP1.

  4. Out of band, RP1 colludes with the IDP and exchanges SHA256(user + RP1)@email.example to user@email.example.

  5. RP1 tells RP2 that user@email.example is shopping for wedding rings

  6. User browses the housing inventory in RP2.

  7. Out of band, RP2 colludes with the IDP and exchanges SHA256(user + RP2)@email.example to user@email.example.

  8. RP2 uses the fact that the user is shopping for wedding rings in RP1 to advertise and filters their housing inventory.

  9. User is surprised that RP2 knows that they are shopping for wedding rings.

10.1.3.3.3. Timing Attacks

The potential for IDPs profiling users based on their visits to RPs § 10.1.3.2.1 Secondary Use can be partially mitigated by hiding the RP from the IDP until after the user has consented to that tracking risk.

However, there is residual risk in cases where the RP and IDP are colluding.

If a credentialed request is sent to the IDP that does not explicitly identify the RP, either of the following would still allow tracking by the IDP (again, possibly not a _bona fide_ IDP that has existing knowledge of the user):

The timing information can enable tracking in the following way:

  1. The RP logs the time at which it invoked the API, and

  2. The IDP logs the time at which it received a credentialed FedCM request from the user, and later

  3. They attempt to link the invocation and the request together using that information.

Notably, this is possible without FedCM using simple cross-origin top-level navigations, but using FedCM for this purpose would worsen the problem if it improved timing resolution or was less visible to users.

See also:

  1. Web Platform Design Principles § safe-to-browse

10.2. Mitigation Strategies

In this section we’ll go over some strategies used in this specification to mitigate the privacy threats.

10.2.1. Minimal Disclosure

There is a series of privacy threats that can be mitigated by disclosing the least amount of identifying information and limiting its use as much as possible. Two notable strategies are described in the sections below.

10.2.1.1. Directed Identifiers

Mitigates:

Note: directed, sharding, partitioning

The problem of RPs joining user data via back-channels is inherent to the proliferation of identifying user data. This can be solved by issuing directed identifiers that provide an effective handle to a user’s identity with a given IDP that is unique and therefore cannot be correlated with other RPs.

In the past, there have been schemes to accomplish this using one-way hashes of, for example, the user’s name, the IDP and the RP.

Note: this mitigation is not robust against § 10.1.3.3.2 Back channel, or the § 10.1.3.2.1 Secondary Use. Also, collaborating RPs might be able to defeat this mitigation by sharing the same CLIENT_ID, although possibly this could be detected and presumably would violate RP agreements with IDPs with § 10.2.5 Pre-registration.

10.2.1.2. Self Presentation

Mitigates:

Note: unbundling issuing from presentation

Preventing tracking of users by the IDP is difficult because the RP has to be coded into the identity token for security reasons, to prevent reuse of the token. There have been cryptographic schemes developed to blind the IDP to the RP while still preventing token reuse in that way (see Mozilla’s personas) but there are other valid uses that the IDP has for knowing the RP, such as fraud and abuse prevention.

10.2.2. Mediation

Mitigates:

IDPs, whom the user has entrusted with their personal data, are currently responsible for ensuring that the user consents to their information being shared. With browser mediation in place, the user agent might have to assume responsibility for ensuring the user understands what is being shared and that it is intentional. This is certainly the case if the browser is able to entirely intermediate the identity flow without showing any IDP web content, but also might be desirable if there are concerns that the IDP is not collecting consent in an adequate manner.

Additionally, a consent prompt preceding the sharing of the RP’s request to the IDP can mitigate risks around IDP tracking of user visits to RPs.

See also:

  1. Web Platform Design Principles § consent

  2. Self-Review Questionnaire: Security and Privacy § user-mediation

  3. Privacy Considerations for Internet Protocols § page-23

  4. Ethical Principles: The web must make it possible for people to verify the information they see

  5. Ethical Principles: The web must enhance individuals' control and power

  6. The Rule of Least Power

10.2.2.1. Verification

Mitigates:

The User Agent can mitigate § 10.1.3.1.1 Cross-Site Correlation by inspecting the contents of the data exchange, and providing the necessary user controls.

For example, it can inspect the email address that is being exchanged and verify whether it is a directed identifier or not (and warn the user proportionally).

10.2.2.2. Activation

The User Agent can mitigate § 10.1.3.3.1 Intrusion by mediating the user controls and offering them proportionally to the intent of the user or the privacy risks involved.

For example, a User Agent can choose to show a loud / disruptive modal mediated dialog when it has enough confidence of the user’s intent or show a quiet / conservative UI hint when it doesn’t.

A User Agent could also choose to control disruption of the user’s experience based on the risks involved.

For example, when a directed identifier is being exchanged it can be more confident of the unintended consequeces and offer a more aggressive user experience, whereas when global identifiers are exchanged a more conservative user experience.

See also:

10.2.3. Policy

Mitigates:

Beyond technical constraints, the browser can recognize explicit assertions by the IDP about the privacy characteristics it provides and rely on those assertions in order to guide the user appropriately. An example is a hypothetical case in which the IDP asserts it will only issue directed identifiers and will not provide identifying information to the RPs out of view of the browser. In that case the browser may not have to warn the user about sharing personalized information.

10.2.4. Denylists

Mitigates:

Any RPs or IDPs observed to be using this API to compromise user privacy in a deceptive or abusive manner could be explicitly blocked from using it, or potentially added to the SafeBrowsing blocklist so that they cannot be loaded at all.

10.2.5. Pre-registration

Mitigates:

Currently, IDPs require that an RP pre-registers and agrees to specific terms before the IDP will issue an ID token to them. This conflicts with the previous mitigation, but can provide a measure of RP accountability.

10.2.6. 2FA

Mitigates:

11. Extensibility

Note: go over the extensibility mechanisms.

12. Acknowledgements

Note: write down the Acknowledgements section.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. Key words for use in RFCs to Indicate Requirement Levels

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CREDENTIAL-MANAGEMENT-1]
Mike West. Credential Management Level 1. 17 January 2019. WD. URL: https://www.w3.org/TR/credential-management-1/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

Informative References

[ETHICS]
W3C TAG Ethical Web Principles. URL: https://www.w3.org/2001/tag/doc/ethical-web-principles
[FINGERPRINTING-GUIDANCE]
Mitigating Browser Fingerprinting in Web Specifications. URL: https://w3c.github.io/fingerprinting-guidance/
[Front-Channel-Logout]
M. Jones. Front-Channel Logout. URL: https://openid.net/specs/openid-connect-frontchannel-1_0.html
[Identity-Use-Cases-in-Browser-Catalog]
V. Bertocci; G. Fletcher. Identity Use Cases in Browser Catalog. URL: https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00
[JWT]
M. Jones; J. Bradley; N. Sakimura. JWT. URL: https://datatracker.ietf.org/doc/html/rfc7519
[LEAST-POWER]
Tim Berners-Lee; Noah Mendelsohn. The Rule of Least Power. 23 February 2006. TAG Finding. URL: https://www.w3.org/2001/tag/doc/leastPower
[OAuth]
D. Hardt. OAuth. URL: https://datatracker.ietf.org/doc/html/rfc6749
[OpenID]
OpenID. URL: https://openid.net/developers/specs/
[PRINCIPLES]
Web Platform Design Principles. URL: https://w3ctag.github.io/design-principles
[PSL-PROBLEMS]
Ryan Sleevi. Public Suffix List Problems. URL: https://github.com/sleevi/psl-problems
[RFC6973]
Privacy Considerations for Internet Protocols. URL: https://datatracker.ietf.org/doc/html/rfc6973
[RFC7258]
Pervasive Monitoring Is an Attack. URL: https://datatracker.ietf.org/doc/html/rfc7258
[SAML]
SAML. URL: http://saml.xml.org/saml-specifications
[Security-Origin-Confusion]
Security Origin Confusion. URL: https://w3c.github.io/webappsec-credential-management/#security-origin-confusion
[TRACKING-DNT]
Roy Fielding; David Singer. Tracking Preference Expression (DNT). 17 January 2019. NOTE. URL: https://www.w3.org/TR/tracking-dnt/
[UNSANCTIONED-TRACKING]
Mark Nottingham. Unsanctioned Web Tracking. 17 July 2015. TAG Finding. URL: http://www.w3.org/2001/tag/doc/unsanctioned-tracking/

IDL Index

enum FederatedCredentialApprovedBy {
  "auto",
  "user"
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  readonly attribute USVString idToken;
  readonly attribute FederatedCredentialApprovedBy approvedBy;
};

partial dictionary FederatedCredentialRequestOptions {
  sequence<(DOMString or FederatedIdentityProvider)> providers;
};

dictionary FederatedIdentityProvider {
  required USVString url;
  USVString clientId;
  USVString nonce;
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  static Promise<void> revoke(USVString accountId);
};

dictionary FederatedCredentialLogoutRequest {
    required USVString endpoint;
    required USVString accountId;
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential : Credential {
  static Promise<void> logout(optional sequence<FederatedCredentialLogoutRequest> logout_requests = []);
};